---
sidebar_label: FAQ
description: |-
  An FAQ page to communicate frequently asked questions concerning feature deprecations.
---
# Feature deprecation FAQ

This page provides frequently asked questions concerning decisions made about OpenBao feature deprecations. Please refer to the [Feature Deprecation Notice and Plans](/docs/deprecation) document for up-to-date information on OpenBao feature deprecations and notice.

- [Q: What is the impact of removing support for X.509 certificates with signatures that use SHA-1?](#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1)
- [Q: What are the phases of deprecation?](#q-what-are-the-phases-of-deprecation)

### Q: what is the impact of removing support for x.509 certificates with signatures that use SHA-1?

OpenBao is built with Go 1.21 or later.  The standard library in Go 1.18 and
later [rejects X.509 signatures](https://go.dev/doc/go1.18#sha1) that use a
SHA-1 hash.

If this issue impacts your usage of OpenBao, you can temporarily work around it by deploying OpenBao with the environment variable `GODEBUG=x509sha1=1` set.
This workaround will fail in a future version of Go, however, the Go team has not said when they will remove this workaround.

If you want to check whether a certificate or CA contains a problematic signature, you can use the OpenSSL CLI:

```shell-session
$ openssl x509 -text -noout -in somecert.pem | grep sha1

    Signature Algorithm: sha1WithRSAEncryption
    Signature Algorithm: sha1WithRSAEncryption
```

Any signature algorithms that contain `sha1` will be potentially problematic.

Here are the use cases that may still use certificates with SHA-1:

#### Auth methods

- [Kerberos Auth Method](/docs/auth/kerberos)
- [Kubernetes Auth Method](/docs/auth/kubernetes)
- [LDAP Auth Method](/docs/auth/ldap)
- [JWT/OIDC Auth Method](/docs/auth/jwt/)
- [TLS Certificates Auth Method](/docs/auth/cert)

#### Database secrets engines

- [Cassandra Database Secrets Engine](/docs/secrets/databases/cassandra)
- [InfluxDB Database Secrets Engine](/docs/secrets/databases/influxdb)
- [MySQL/MariaDB Database Secrets Engine](/docs/secrets/databases/mysql-maria)

#### Secrets engines

- [Kubernetes Secrets Engine](/docs/secrets/kubernetes)
- [LDAP Secrets Engine](/docs/secrets/ldap)
- [PKI Secrets Engine](/docs/secrets/pki/)

### Q: what are the phases of deprecation?

OpenBao implements a multi-phased approach to deprecation. The intent of this approach is to provide sufficient warning that a feature will be removed and safe handling of stored data when the associated feature has been removed.

The phases of deprecation are also known as "Deprecation Status". These statuses are currently reflected in builtin plugins and are exposed via the OpenBao `auth`, `secrets`, and `plugins` CLI/API endpoints. For more information, refer to the corresponding documentation.

The four phases of deprecation are: `Supported`, `Deprecated`, `Pending Removal`, and `Removed`.

**Note:** Deprecation Status currently only applies to builtin `auth` and `secrets` plugins. All external plugins will report a status of `n/a`. This is expected behavior.

#### Supported

This is the default status and reflects a feature which is still supported. There is no unique behavior or functionality associated with this status.

#### Deprecated

This status reflects a feature which has been marked for deprecation in a later release of OpenBao. This is the first phase of the deprecation process. A status of `Deprecated` has two effects:

1. After an upgrade, any existing `Deprecated` feature (builtin auth/secrets plugins enabled via CLI or API prior to upgrade) will log `Warn`-level messages on unseal.

2. All new usage of `Deprecated` features will log `Warn`-level messages.

3. All `POST/GET/LIST` endpoints associated with this feature will return `warnings` in response data.

#### Pending removal

This status reflects a feature which has been officially deprecated in this release of OpenBao. This is the first phase in the process that fundamentally alters the behavior of OpenBao. The effects are two-fold:

1. After an upgrade, any existing `Pending Removal` feature (builtin auth/secrets plugins enabled via CLI or API prior to upgrade) will log `Error`-level messages to the OpenBao log and cause an immediate shutdown of the OpenBao core.

2. Any new `Pending Removal` will fail and log `Error`-level messages to the OpenBao log and CLI/API.

##### VAULT_ALLOW_PENDING_REMOVAL_MOUNTS

The `Pending Removal` behavior may be overriden using a new environment variable: [`VAULT_ALLOW_PENDING_REMOVAL_MOUNTS`](/docs/commands/server#vault_allow_pending_removal_mounts). This environment variable effectively allows all `Pending Removal` features to be treated as `Deprecated`.

#### Removed

This status reflects a feature which has been officially removed from OpenBao. `Removed` is the last phase of the deprecation process. During this phase, code for this feature no longer exists within OpenBao.

1. After an upgrade, any existing `Removed` feature will log `Error`-level messages to the OpenBao log and cause an immediate shutdown of the OpenBao core.

2. Any new `Removed` features will fail and log `Error`-level messages to the OpenBao log and CLI/API.

#### Migration path

In order to successfully upgrade, use of the `Removed` feature must be discontinued. To accomplish this:

1. Downgrade OpenBao to a previous version.

2. Replace any `Removed` or `Pending Removal` feature with the [preferred alternative feature](#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines).

3. Upgrade to latest desired version.
